原本以為 Day.10 的主題會是網路斷線，沒想到今天先斷線的是我們的參賽資格。
因為團隊中有一篇文章忘記在期限內發布，我們的團體挑戰正式宣告中斷。這件事證明了，鐵人賽最危險的 Single Point of Failure，不一定是核心交換器，也可能只是那顆忘記按下「發布」的按鈕。
團隊模式雖然已經顯示 Offline，但我的個人挑戰還能繼續。既然無法再一起抵達終點，那我就切換成 Standalone Mode，把剩下的二十天走完。
畢竟做這行遲早都會遇到突發狀況。系統斷了要找替代路徑，隊伍斷賽也是一樣。
所以，Day.10 照常上線。
隊伍可以斷線，文章不能。
「剛才網路不能用，現在又好了。」
這句話是企業 IT 排錯裡，精神消耗特別高的一種類型。
完全斷線其實比較好處理。
因為故障持續存在，我們可以查看現場狀態、執行測試、替換設備，再根據結果一步步縮小範圍。
間歇性問題就不一樣了。
使用者回報時不能用，等我們走到現場，網站已經正常開啟。Ping 沒有掉包、網卡顯示已連線，設備 Log 乍看也沒有異常。
你只好先回座位。
五分鐘後，訊息又來了：
現在又斷了。
設備彷彿知道你在看它，只要 IT 人員靠近就立刻恢復正常，還有人開玩笑要掛張我們的照片在這裡鎮守。而這當然不是什麼靈異現象，只是我們缺少故障發生當下的資料。
處理間歇性問題，重點不是一直守在現場等它發作，而是建立一套能留下時間與狀態的觀測方法。
使用者說網路不穩，可能代表：
這些現象的調查方向並不相同。
因此，第一步仍然是把描述轉成可驗證的問題。
例如：
Client A 從上午 9:00 起，每隔約十至十五分鐘會中斷一至兩分鐘。中斷期間無法 Ping Default Gateway，但同區域其他使用者正常。
這段描述已經提供：
比「網路怪怪的」有用太多。
間歇性問題最重要的資訊，通常是時間。
至少記錄：
可以簡單整理成表格：
| 時間 | 現象 | Gateway | 內部 Server | 外部 IP | DNS |
|---|---|---|---|---|---|
| 09:10 | 視訊卡頓 | 正常 | 正常 | 延遲升高 | 正常 |
| 09:24 | 完全斷線 | 失敗 | 失敗 | 失敗 | 失敗 |
| 09:26 | 自動恢復 | 正常 | 正常 | 正常 | 正常 |
| 09:39 | 網頁逾時 | 正常 | 正常 | 正常 | 失敗 |
當資料逐漸累積後，可能會看出不同模式。
例如：
時間規律通常是找出根因的重要線索。
遇到網路不穩，很多人會持續 Ping：
8.8.8.8
這能觀察外部連線，但如果出現 Timeout，仍然不知道問題發生在哪一段。
比較有效的方法，是同時測試不同位置。
例如：
測試一：Default Gateway
測試二：內部 Server
測試三：外部 IP
測試四：DNS Query
假設 Client 位於：
10.10.20.35/24
可以測：
ping -t 10.10.20.1
ping -t 10.10.50.10
ping -t 8.8.8.8
再定期執行 DNS 查詢。
不同結果可以提供不同方向。
可能原因：
因為連最靠近的 Gateway 都失敗，問題很可能位於 Client 到 Gateway 之間。
可能方向：
可能原因：
可能方向：
例如：
這時應查看：
不應繼續只靠 Ping 判斷。
持續 Ping 能幫助記錄：
例如：
Reply from 10.10.20.1: time=1ms
Reply from 10.10.20.1: time=2ms
Request timed out.
Request timed out.
Reply from 10.10.20.1: time=1ms
這至少能證明某個時間區間沒有收到 ICMP 回覆。
但 Ping 不能直接證明：
而且某些設備會降低 ICMP 回覆優先級。
在高負載時，Router 可能先處理轉送工作，不積極回覆對自己的 Ping。這時設備 Ping 丟包，不代表穿過它的資料流量一定也丟包。
因此，Ping 是觀測工具，不是最終根因。
兩者都會讓使用者感覺網路很差，但意義不同。
代表部分封包沒有成功抵達或沒有收到回覆。
可能造成：
常見原因：
封包仍然抵達，但花費時間變長。
可能原因：
Jitter 是延遲變化程度。
例如：
10 ms
12 ms
150 ms
15 ms
200 ms
平均延遲可能還沒有高到完全不可用，但變化非常大。
對以下即時服務特別有影響：
因此，「平均 Ping 只有 30 ms」不代表視訊一定穩定，還要看 Loss 和 Jitter。
如果只有一位使用者回報不穩，可以在同一時間對正常 Client 進行相同測試。
例如：
異常 Client：Gateway 每十分鐘丟包
正常 Client：Gateway 全程正常
問題比較可能集中在：
如果兩台 Client 同時丟包，則可能是：
對照組能幫助我們分辨：
這是整個環境的問題，還是只有這台設備遇到？
沒有對照組時，很容易把 Internet 的正常波動誤認為本地故障，也可能把單機問題錯判成公司網路事故。
如果使用者透過有線網路連線，優先檢查以下項目。
交換器介面出現持續增加的：
可能與以下原因有關：
不要只看總數，要比較一段時間內是否增加。
如果使用者每次斷線時 CRC 都快速增加，這是很有價值的關聯。
查看 Switch Log 是否出現：
Interface Gi1/0/17 changed state to down
Interface Gi1/0/17 changed state to up
如果時間和使用者斷線一致，就應檢查：
如果協商結果異常，可能在小流量下看似正常，大流量時效能突然崩壞。
檢查兩端是否：
若一端 Full、另一端 Half，可能出現 Collision、CRC 和嚴重效能問題。
Output Drop 可能代表介面送出流量時，Queue 已滿。
常見於：
有 Drop 不一定表示硬體故障，也可能是流量超過可用頻寬。
此時應觀察：
無線網路的間歇性問題比有線更常見，因為傳輸媒介是共享的空氣。
同一個 SSID 可能由多台 AP 提供。
使用者說：
二樓可以，三樓不行。
或：
坐在座位上不穩，走到會議室就正常。
這可能表示問題只出現在特定 AP。
需要記錄：
如果只記 SSID，資訊還不夠。
同一個 SSID 底下可能有十幾台 AP，使用者實際連到誰才是關鍵。
RSSI 代表接收訊號強度。
數值通常是負數，例如：
-45 dBm：強
-65 dBm：普通至良好
-75 dBm：偏弱
-85 dBm：很弱
實際門檻仍受裝置、頻段與應用需求影響。
SNR 是訊號和背景雜訊的差距。
即使 RSSI 看起來不差，如果環境雜訊很高，SNR 仍可能很低，導致大量重傳。
因此，Wi-Fi 滿格不代表品質一定好。
AP 聲音很大，不代表它聽得清楚 Client 回話。
Wi-Fi 使用共享媒介，同一頻道上的裝置需要競爭 Airtime。
Channel Utilization 過高時，Client 必須等待更久才能傳送。
可能原因：
症狀可能是：
使用者移動時，Client 會決定何時從舊 AP 漫遊到新 AP。
如果 Client 太黏著舊 AP，可能出現：
Roaming 通常由 Client 主導，AP 只能提供協助。
因此，不一定是 AP「不願意放人」，也可能是 Client Driver、功率或漫遊策略。
如果問題每天在固定時間出現，應調查環境中同時發生的工作。
常見項目：
例如每天中午網路變慢，可能不是交換器中午想休息，而是大量員工同時看影片、更新軟體或進行雲端同步。
每天凌晨固定斷線，則可能與備份、線路維護或設備排程有關。
事件時間和排程資料對上後，根因通常會靠近很多。
正常的 DHCP Renew 不應明顯中斷網路。
Client 通常在租期尚未過期前，就向 DHCP Server續租。
但如果：
就可能在固定時間附近發生連線問題。
可以比較：
如果每次故障剛好接近租約事件，就值得深入調查。
但不要看到週期性就直接宣判 DHCP。週期性只是特徵，很多排程都能製造相同外觀。
如果 DNS Server 偶爾無法回應，使用者可能覺得：
已經解析過、仍在 Cache 裡的名稱可能可以使用；新的查詢則會 Timeout。
因此，同一時間測試：
Ping 外部 IP
nslookup 外部名稱
很重要。
如果 IP 持續正常，只有 DNS Query 間歇失敗，問題就不應繼續被描述成整體網路斷線。
MTU 是網路介面能傳送的最大封包大小。
經過 VPN、PPPoE 或 Tunnel 時，額外 Header 會占用空間。
如果封包過大，而路徑又無法正確 Fragment 或回報：
ICMP Fragmentation Needed
就可能出現：
這類問題常被稱為 Path MTU Discovery Black Hole。
因為小流量與小封包看似正常，問題只在特定資料大小出現，所以很像間歇性應用故障。
調查時可以比較不同封包大小與 DF 設定，但變更 MTU 前應先確認實際路徑和 Tunnel Overhead，不能看到 VPN 就隨便把 MTU 調得很小。
Layer 2 Loop 可能引發：
有時 Loop 不是一直存在。
例如有人把線接成環路，偶爾插拔；或某台設備啟動後才 Bridge 兩個介面。
症狀可能是：
這時持續 Ping 只能看到網路很慘，真正重要的是 Switch 的：
遇到疑似 Loop 時，要依既有流程隔離範圍，避免直接亂拔核心上聯。拔錯那條，原本只是網路慢，會立刻升級成真的全斷。
Stateful Firewall 會記錄連線狀態。
如果 Session Table、Timeout 或資源出現問題，可能造成：
需要查看：
如果只有某種應用在固定閒置時間後斷線，可能與 Session Timeout 有關。
例如 RDP 閒置三十分鐘後斷線，重新連線又正常，就不太像實體線材每三十分鐘準時鬆一次。
網路測試需要一定樣本。
執行四次 Ping，出現一次 Timeout，不足以立刻證明整條網路有嚴重問題。
可能原因包括：
反過來，現在連續十次都成功，也不能推翻使用者過去一小時斷線十次的紀錄。
判斷間歇性問題需要：
不要讓單次成功或失敗控制整個結論。
可以透過腳本定期記錄：
例如每十秒寫入：
2026-07-23 09:10:00, gateway=1ms, server=3ms, internet=8ms, dns=20ms
2026-07-23 09:10:10, gateway=timeout, server=timeout, internet=timeout, dns=failed
2026-07-23 09:10:20, gateway=1ms, server=3ms, internet=9ms, dns=21ms
當使用者回報 09:10 左右斷線時，就能看到所有測試是否同步異常。
監測頻率也要合理。
每毫秒測一次不但沒必要，還可能讓監測本身變成額外負載。目標是捕捉問題，不是用測試工具對網路進行壓力測驗。
要把 Client、Switch、Firewall、AP 和 Server 的事件串起來，設備時間必須大致一致。
如果：
同一場事故會像分散在不同平行宇宙。
因此企業環境應使用 NTP，並記錄：
查間歇性問題時，時間戳就是把不同證據串在一起的線。
沒有正確時間，Log 再多也只是一大片不太合作的文字。
如果問題原本每十分鐘發生一次，修正後測試三十秒就結案，說服力不高。
至少要經過原本容易發生的時間窗口。
例如：
原本每十分鐘斷線
→ 觀察至少數個週期
原本每天中午發生
→ 等下一個相同時段驗證
原本大型傳輸才出現
→ 重新執行相同傳輸
原本移動樓層時發生
→ 重走相同漫遊路徑
修復驗證應盡量重現原始條件。
如果暫時無法再次發生，也要記錄：
不能只寫：
現在正常，結案。
這句話和「問題自己好了」的資訊量差不多，都很省字，也都救不了下次的自己。
確認：
找正常 Client 在同時間執行相同測試。
同時測：
依情況確認：
將使用者回報、監測與設備 Log 放在同一時間軸。
保留原值，記錄變更與預期結果。
確認問題沒有在相同條件下再次發生。
完全斷線時，故障狀態一直在那裡等你調查。
間歇性問題則必須透過監測，把短暫發生的現象保存下來。
最重要的方法包括：
不要只問：
現在通不通？
更應該問：
問題發生時，哪個測試點最先失敗？哪些設備同時受到影響？
今天完成後，我們已經從實體連線、DHCP、DNS 和 Gateway，一路建立出基本的端點排錯邏輯。
iThome鐵人賽
看影片追技術